A distributed object/services system typically consists of three major parts;    1) a mechanism to locate objects/services and object/services factories;    2) a data transmission format; and    3) a transport mechanism.
These three parts are generally implemented via very separate mechanisms. For example one could envisage a system in which an LDAP (Lightweight Directory Access Protocol) directory structure is used to locate objects/services; SOAP (Simple Access Object Protocol) is used as the data transmission format; and a messaging product such as IBM's WebSphere MQ is used as the transport mechanism.
FIG. 1 provides an overview of how a system with a separably maintainable directory structure typically functions. Client 10 requests an object/service 40 from server 20 (e.g. BANK). Server 20 performs a lookup in directory 30 and discovers that BANK resides on system 1.
Server 20 then issues a request to system 1 for the BANK service/object. This may involve calling a method on BANK and passing associated parameters (e.g. debit(S Todd, 100)).
Implementing each of the three mechanisms discussed above separately is both difficult and time-consuming. For example, implementing the mechanism to locate objects/services requires not only the creation and maintenance of a directory structure 30 but also code to provide fault-tolerance in the event of a directory failure. Such fault tolerance is often provided by keeping a backup copy of the directory in synchronisation with the primary copy (i.e. replication). In addition there are other considerations such as security.
Thus there is a need in the industry to reduce the overhead associated with the implementation of these three parts of a distributed object/services system.